As is known, Application Service Providers (ASPs) are hosted at a third party infrastructure (hereafter, the Computing Utility) that provides capabilities such as servers, network connectivity and storage. The Internet is the world's largest network, and it has become essential in organizations such as government, academia and commercial enterprises. Transactions over the Internet are becoming more common, especially in the commercial arena. Commercial entities increasingly operate as ASPs by running their customer-facing applications (e.g., product catalogues) on Computing Utilities.
ASPs often have agreements with their customers that specify service level objectives in terms of metrics such as response times, throughputs, and availability. These agreements are detailed in ASP Service Level Agreements (SLAs). SLAs may specify penalties if the service level objective is not met. We refer to the penalties incurred by an ASP as “SLA costs”.
ASPs use the resources of the Computing Utility to deliver services, and the Computing Utility receives revenue for resources consumed by the ASP. This revenue may be calculated in many ways, such as fixed prices for a resource type, prices that are adjusted dynamically in response to loads, and prices that are negotiated between the ASP and the Computing Utility. Thus, there may be “Computing Utility SLAs” that specify how resource prices are computed and the penalties to be paid by the Computing Utility to ASPs if contracted resources are unavailable or are reclaimed before the ASP releases the resource.
As businesses, ASPs and Computing Utilities may utilize business metrics such as costs, revenues, and profits. While other business metrics may be used by ASPs, we illustratively refer to cost. Thus, a key challenge to the ASP is to determine the timing of resource requests and releases so as to minimize ASP total cost. ASP total cost is the sum of the SLA penalties and the cost of the resources used. We use the term “ASP resource action” to refer to ASP resource requests and releases.
There is a corresponding challenge for Computing Utilities in that they must determine which ASP resources should be allocated and when the resources should be reclaimed. We refer to these as “Computing Utility resource actions.” While other business metrics may be used by Computing Utilities, we illustratively refer to profits.
Achieving these business-oriented optimizations requires an ability to calculate business metrics (e.g., cost, revenue, and profit) associated with resource actions. Thus, there is a need for systems and methods for performing the appropriate business metric calculations for ASPs and Computing Utilities and then searching for an allocation that optimizes the business metric.
The general concept of optimization is well known. Much work has been done with applying optimization to practical problems (e.g., U.S. Pat. No. 6,459,944 to Maturana, entitled “Self-optimizing Industrial Control System Using a Specific Process to Evaluate Bids”), although not to the structure of business-oriented cost functions used in Computing Utilities. Work in the area of negotiation has also been performed (e.g., U.S. Pat. No. 5,495,412 to Thiessen, entitled “Computer-based Method and Apparatus for Interactive Computer-assisted Negotiation”) and policies (e.g., U.S. Pat. No. 5,164,988 to Metyas et al., entitled “Method to Establish and Enforce a Network Cryptography Security Policy”). Work specifically in the area of computing utilities (e.g., “Using a Utility Computing Framework to Develop Utility Systems,” T. Eilam, IBM Systems Journal, March, 2004 and J. Rolia et al., “Automating Enterprise Application Placement in Resource Utilities,” Distributed Systems Operations and Management, 2003) do not address how to optimize business metrics.